IMS is a hierarchical database management system (HDBMS) developed by International Business Machines Corporation. IMS has wide spread usage in many large enterprises where high transaction volume, reliability, availability and scalability are of the utmost importance. IMS provides software and interfaces for running the businesses of many of the world's large corporations. However, companies incorporating IMS databases into their business models typically make significant investments in IMS application programs in order to have IMS perform meaningful data processing work particularly tailored to the needs of their respective enterprises. IMS application programs are typically coded in COBOL, PL/I, C, PASCAL, Java or assembly language. These application programs may perform IMS database functions by making Data Language One (DLI) calls to invoke needed IMS processing.
A batch IMS application program may have been developed to run as a stand-alone batch application outside of the IMS subsystem environment. These programs are characteristically invoked by specifying either “PARM=DLI” or “PARM=DBB” on the Job Control Language (JCL) EXEC statement and are henceforth referred to as DLI/DBB batch applications.
A batch IMS application may also be developed to run as a BMP batch application executing under the control of an IMS subsystem. These programs are characteristically invoked by specifying “PARM=BMP” on the JCL EXEC statement and are henceforth referred to as BMP batch applications.
Those of ordinary skill in the art will recognize that IMS relies on the use of commit points in preserving the integrity of data managed by IMS. A commit point is defined as an indicator to IMS that a program has finished a unit of processing, and that the processing it has done is accurate. A commit point, for example, occurs when a program terminates normally, retrieves a new message from the IMS message queue or issues a checkpoint call. An eight-character checkpoint ID is generated by the application and utilized by IMS to uniquely identify each checkpoint that is taken.
IMS performs processing in association with a commit point to ascertain that, synchronous with the commit point, all data is in a known and valid state. This processing comprises hardening (i.e. making permanent) all modified data up to this point in time and ensuring that all segment locks associated with the application are released. In an online environment, all enqueue/dequeue blocks, which were used for locking segments, are released. Further, the current position in all databases (except GSAM or sequential files) is reset to the start of the database. The application program may also save any other data deemed useful to the application within a checkpoint save area. These save areas are formatted by the application program in accordance with the needs of the application program in performing a subsequent restart operation.
In view of the commit point processing briefly discussed supra, an application program has the obligation to reestablish database positioning prior to the continuation of processing following a commit point. This repositioning is performed within the application program, typically by deploying logic to issue a retrieve call to the segment reflecting current positioning prior to the commit point. This retrieve call is not automatically issued by IMS, but must be driven by the logic of the application program.
If an application program abnormally terminates before reaching the next commit point, IMS performs processing to reset the database to the state associated with the most recently completed commit point. This processing includes backing out all of the changes the application program has made to the database since the last commit point. In an online environment, this backout will be performed by IMS itself; and in a batch environment, the backout will be performed by the batch backout utility. Additionally, IMS discards any output messages written to the message queue by the application since the last commit point and releases any locks acquired by the application since the last commit point.
Accordingly, an application that is not issuing checkpoint calls or retrieving messages from the message queue will have all modifications backed out since the initial invocation of the application program. This is especially detrimental in those instances where the application program has been running for an extended period of time.
A batch IMS application, either a DLI/DBB batch application or a BMP batch application, may be initially developed without the deployment of commit point processing. This may be a reasonable development approach at the time an application is originally developed. However, various conditions and environmental factors may change over time making it desirable to add commit point processing at some future time.
For example, a database may grow in size over time such that higher processing volumes are encountered. This can result in excessive contention for record locking resources (such as enqueue/dequeue blocks in IMS), or negatively impact response time where needed segments are locked out from other online applications. Furthermore, without taking frequent commit points, an application may experience a significant recovery cost in the event of an abnormal termination. This is because all of the work performed by the application must be backed out and redone going all the way back to the beginning of the job. This may be an unacceptable impact for an enterprise that is executing long running jobs.
Furthermore, it is frequently desirable for a particular DLI/DBB batch application to be converted to a BMP batch application. For example, program recovery procedures may be greatly simplified by changing from a DLI/DBB batch application to a BMP running under the IMS subsystem. This simplification occurs because the BMP execution environment provides for advanced logging capabilities utilizing a single system log as well as automatic data backout in the case of an abnormal termination. Furthermore, the ability to share critical IMS resources is enhanced under the IMS subsystem since resources may be locked and unlocked dynamically as required, rather than locking these resources for the entire duration of the DLI/DBB batch application. However, converting and running a DLI/DBB batch application as a BMP application may encounter unwanted and unnecessary abnormal terminations when commit point processing is not being performed by the batch application. This is because, within the BMP online processing environment, enqueue/dequeue blocks must be periodically and timely released by an application to avoid exhaustion of the finite supply of these blocks, and it is commit point processing that is used to accomplish this periodic and timely release.
A novel technique for implementing commit point processing into an existing application is disclosed in the Auto-commit Disclosure, identified supra under the heading “CROSS-REFERENCE TO RELATED APPLICATIONS.” A batch application program embodying the teachings contained within the Auto-commit Disclosure is hereinafter referred to as an “auto-commit batch application program.”
The creation of an auto-commit batch application program may resolve numerous problems, as briefly discussed supra; however, the creation of an auto-commit batch application program also provides an opportunity to utilize automatically created checkpoint IDs to achieve an auto-restart capability within an IMS batch application. It is therefore an object of the present invention to assist the database administrator and database programmer with a novel and non-obvious solution for efficiently enhancing a batch IMS application to utilize checkpoint IDs for the purpose of automatically restarting a failed batch application.
An IMS batch application that has been transformed into an auto-commit batch application is void of any restart-related logic at the time of transformation. This is because the IMS batch application, prior to its transformation, could not have anticipated the existence of checkpoint IDs available for implementing any auto-restart logic for an application. Therefore, an auto-commit batch application program requires the addition of restart logic in order to utilize the automatically created checkpoint IDs.
Modifying an existing batch application to incorporate restart logic can be an intimidating task for even the best of programmers. This is because substantial code changes must be made with exacting precision, possibly with minimal program documentation and/or loss of contact with the original developers of the existing batch application. Furthermore, all or a portion of the source code may be missing. There may also be a concern that the source code does not match the compiled execution object code, making modification impractical due to the high risk of introducing regression problems into the application program.
IMS enterprises may delay receiving, or entirely forego, the many advantages of an auto-restart capability because of the extensive coding effort, discussed supra, involved with making the transition to an auto-restart enabled batch application. Even where the difficulty of inadequate documentation is not a factor, the complexity of implementing restart logic into an application may slow the development process, with significant increase in the coding and testing effort.
Accordingly, there is a great need for a solution to facilitate and expedite the addition of restart logic to an existing batch IMS application, as well as solutions to speed the development of new batch applications requiring automatic restart capability.